A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention relates to the field of computer networking, and, more particularly, to apparatus and methods that allow a transport protocol executing on one computer system to be utilized by network applications executing on a second computer system.
2. Description of the Prior Art
The ability for heterogeneous computer systems to communicate with each other over a network using standard ISO and/or proprietary networking protocols is known. Most computer systems have some form of networking architecture that enables the computer system to perform networking in accordance with those protocols. For example, the generic networking platform with the standard 7 layer ISO Reference Model includes a network stack: applications, presentation, and sessions levels under user control, and transport, network, data link, and physical levels under kernel (operating system) control. Typical networking architectures comprise both system software and hardware.
FIG. 1 is a block diagram illustrating the components of a netvorking architecture employed by a Unisys A Series enterprise server 10 in order to communicate with other hosts, or nodes, on a network 15. The A Series enterprise server 10 executes the Unisys MCP operating system 12, and has an I/O subsystem that comprises one or more I/O Modules (IOM) 14 housed within the A Series chassis. The IOM 14 implements a Unisys proprietary I/O bus architecture referred to as CS-BUS II or CS-Bus III (hereinafter xe2x80x9cthe CS Busxe2x80x9d). A plurality of card slots, e.g. slots 16a-d, are provided for connecting interface cards, referred to as xe2x80x9cchannel adaptersxe2x80x9d, into the CS Bus. Different groups, or racks, of channel adapter slots are each controlled by a Channel Manager Unit (CMU) (e.g., CMUs 18a, 18b). An IOM can contain several CMUs, each of which controls a different rack of channel adapter card slots via the CS-Bus. The CMUs manage the physical and data layers of the CS-Bus data transfer protocol.
Channel adapter cards, which each may occupy one or more channel adapter card slots within the IOM 14, provide various connectivity solutions for the A Series enterprise server 10. For example, Unisys provides a channel adapter card that implements the Small Computer System Interface(SCSI) protocol for connecting SCSI peripherals to the enterprise server 10.
For network connectivity, Unisys provides several channel adapters to support various physical networking protocols. These channel adapters are generally referred to as network processors (NP). For example, Unisys ICP22 and ICP26 network processors are channel adapter cards that implement the Ethernet network protocol and can be used to connect an A Series enterprise server 10 to an Ethernet network. Unisys also provides network processors for connectivity to FDDI and ATM networks. As shown in FIG. 1, a number of different network processors (e.g., NPs 20a, 20b, and 20c) can be installed in respective channel adapter slots (e.g., slots 16b, 16c, and 16d) of the IOM 14, in order to provide different network connectivity solutions.
As shown in the more detailed view of network processor 20c (installed in channel adapter slot 16d), a network processor may comprise a plurality of different lines, e.g., Line0, Line1 Y LineN, where a line represents a physical endpoint within a network. For example, the Unisys ICP22 network processor has two lines, each of which comprises a separate Ethernet connectionxe2x80x94one line could be connected to one Ethernet network, and the other to a different Ethernet network.
Each line of a network processor can have one station group defined on that line. A station group consists of one or more stations. A station is a logical endpoint that represents a logical dialog on that line. Thus, more than one logical dialog can take place over a given line of a network processor. This is achieved through multiplexing. For example, with a correction-oriented networking protocol, such as the Burroughs Network Architecturexe2x80x94Version 2 protocol (BNAv2), one station may represent a logical dialog with one other BNAv2 host on the network, whereas another station may represent a logical dialog to a different BNAv2 host. As illustrated in FIG. 1, for example, Station0 of LineN may represent a logical dialog with BNAv2 host 22, and Station1 of LineN may represent a logical dialog with BNAv2 host 24. For networking protocols that are not connection-oriented, like the Internet Protocol (IP), only one station needs to be defined to handle all communications for that protocol stack. For example, in FIG. 1, StationN of LineN could be defined as the logical endpoint for all IP traffic over LineN. A Local Area Network Station Group (LANSG) module 26, which comprises software executing on the network processor 20c, provides callable procedures for creating and maintaining stations and station groups on the various lines of the network processor 20d and for sending and receiving data over them.
Other software components that execute on the network processor 20c include a Queue Service Provider (QSP) module 28, which handles the passing of messages between the NP Support 40 and the channel adapters. QSP module 28 also multiplexes and demultiplexes data for all stations defined on a given NP. Some data is blocked together for efficiency; other data is not. Other components include two stub modulesxe2x80x94a Network Services Manager stub (NSM-stub) 30 and a Link Layer Manager stub (LLM-stub) 32xe2x80x94which interface with corresponding modules of a Core Network Services (CNS) software component 34, to and from modules within the MCP environment.
Generally, a network processor (e.g., NP 20a, 20b, or 20c) implements the data link and physical layers of the 7-layer ISO Reference Model. Higher level networking protocols that a client application 46 may wish to employ in order to communicate with applications running on different hosts of the network 15, such as the BNA version 2 (BNAv2) and TCP/IP networking protocols, are implemented as network protocol providers on the A Series system 10. A network protocol provider is a software module that implements these higher level networking protocols. For example, Unisys provides both BNAv2 Host Resident Network Provider (HRNP) modules and TCP/IP HRNP modules. In the example of FIG. 1, a BNAv2 HRNP 42 and a TCP/IP HRNP 44 are shown.
The Core Network Services (CNS) software 34 provides support for the network protocol providers 42, 44 and handles the initialization and maintenance of network processors and the station groups defined thereon. Specifically, CNS 34 comprises a Network Services Manager (NSM) 36 that initializes and manages the network processors (e.g., 20a, 20b, 20c) installed in the system, and a Link Layer Manager (LLM) 38 that initializes and maintains the identity and attributes of each station group defined on a given network processor. Another component (not shown) of CNS 34 validates attributes associated with station groups and stations created on a network processor. These attributes are passed between the network processor and CNS 34 via a control dialog when the stations are defined. Like the stub procedures for the NSM and LLM modules 36, 38, network processors also have a stub procedure (LLAH, not shown) that corresponds to the attribute handler of CNS 34. An NPSUPPORT software library 40, as well as portions of the MCP operating system 12, provide routines and procedure calls that serve as an interface between a network processor and the CNS 34 and network protocol providers 42, 44, and control loading of software to the NPs and dumping of their state.
Each network processor has an associated identifier that uniquely identifies that network processor within the system 10. When a network processor is initialized and brought on-line, the NSM-stub 30 in the network processor interfaces with the NSM 36 of CNS 34 via a control dialog in order to pass its identifier to the NSM 36. The NSM 36 manages the identifiers of all active network processors.
Each station group and station defined for a given network processor also has a unique identifier associated with it. Via a control dialog established between the LLM-stub 32 on the network processor and the LLM 38 of CNS 34, the station and station group identifiers are passed to the LLM 38 during initialization. Within the LLM 38, a station corresponds to a connection, and a station group corresponds to a connection group.
As mentioned above, the ability to define multiple stations (i.e., a station group) on a single physical line of a network processor is achieved through multiplexing. Specifically, the QSP 28 in the network processor multiplexes inbound and outbound data for multiple stations on a given line. Moreover, the QSP 28 is responsible for distributing request and response data between the NSM 36 and NSM-stub 30 and between the LLM 38 and LLM-stub 32. To that end, each entity on the network processor that receives outbound data from the MCP 12, including every station, the NSM-stub 30, and the LLM-stub 32, is assigned a unique Remote Queue Reference (RQR) by the QSP 28. The NSM-stub RQR is reported to the NSM 36 within CNS 34 via NPSUPPORT 40 when the NP is loaded. The LLM-stub RQR is reported to the LLM 38 via the NSM 36 by the NSM-stub 30 when the network processor initializes. All of the station RQRs are reported to the HRNPs 42, 44 as the stations open.
When a client application is required to send data via network 15 to some other host or node on the network 15, such as another BNAv2 Host 22, 24 or another TCP/IP host 25, it invokes the services of the appropriate network protocol provider, e.g. 42, 44. The network protocol provider 42, 44 determines the appropriate network processor and station on which the data is to be output, adds protocol headers for each of the network layers, and makes a corresponding request to the MCP 12 that includes the identifier of the network processor and the RQR of the station. The data and associated RQR are passed from the MCP 12 to the QSP 28 on the network processor (e.g., network processor 20c), which, in combination with the LANSG module 26, sends the data out to the network 15 via the appropriate line (e.g., Line0, Line1, Y or LineN) as part of the logical dialog represented by the designated station.
When data is received from the network 15 on a given line, the LANSG module 26 determines, from header information associated with the data, the station (i.e. logical dialog) for which the data is intended. The LANSG and QSP modules 26, 28, in combination with portions of the MCP 12 and NPSUPPORT library 40, pass the received data to the appropriate network protocol provider 42, 44 associated with that station, along with an indication of which station received the data. For example, one of the stations on LineN of the network processor 20c of FIG. 1 (e.g., station0) may be defined as the logical endpoint for the BNAv2 HRNP 42, while a different station (e.g., station1) may be defined as the logical endpoint on which all IP traffic over LineN is received for the TCP/IP HRNP 44. When a frame of data is received from the network on LineN, the LANSG module 26 determines from header information which of the network protocol providers (i.e., stations) is intended to receive the data. This determination is performed in accordance with the methods described in commonly assigned, U.S. Pat. No. 5,379,296, entitled xe2x80x9cMethod and Apparatus for Interfacing a Workstation to a Plurality of Computer Platformsxe2x80x9d (Johnson et al.).
In addition to its use in A Series computers, the foregoing networking architecture is also employed in Unisys ClearPath HMP NX enterprise servers. A ClearPath HMP NX server comprises an A Series enterprise server tightly integrated with a server running Microsoft Window NT. Please note that xe2x80x9cMicrosoft,xe2x80x9d xe2x80x9cWindows,xe2x80x9d and xe2x80x9cWindows NTxe2x80x9d are registered trademarks of Microsoft Corporation. Additional information concerning the foregoing networking architecture can be found in the following documents, each of which is available from Unisys Corporation, assignee of the present invention, and each of which is hereby incorporated by reference in its entirety:
ClearPath HMP NX Series with Windows NT Network Services Implementation Guide (Part No. 4198 6670); BNA/CNS Network Implementation Guide, Volume 2: Configuration (Part No. 3789 7014);
ClearPath HMP NXSeries with Windows NT Implementations and Operations Guide (Part No. 8807 6542);
ClearPath HMP NXSeries with Windows NT Migration Guide (Part No. 8807 7730);
Networking Capabilities Overview (Part No. 3789 7139);
Networking Operations Reference Manual, Volumes 1 and 2: Commands and Inquiries (Part No. 3787 7917); and
Networking Products Installation Guide (Part No. 4198 4840).
Using a Unisys ICP22 network processor, which is an Ethernet-based channel adapter, it has been possible in the past for a Unisys A Series enterprise server to communicate with a workstation or personal computer (PC) over a network. An example of this ability is illustrated in FIG. 2. In this example, the A Series enterprise server 10 communicates with an Intel-based workstation 48 running the Microsoft Windows NT operating system (hereinafter xe2x80x9cthe NT serverxe2x80x9d). The A Series enterprise server 10 is connected to the network via network processor 20a, which may, for example, be a Unisys ICP22 Ethernet-based network processor.
The I/O subsystem of the NT server 48 comprises portions of the NT operating system kernel, an EISA or PCI bus 52, and appropriate device driver software. To provide network connectivity, a network interface card (NIC) 50 is installed in an available bus slot on the NT server 48. The NT server may support one or both of the PCI and EISA bus standards. NICs are available for both bus standards.
A NIC device driver 54 that typically is sold with the NIC card 50 is installed in the kernel space of the NT operating system. The NIC device driver 54 interfaces with a higher level network protocol provider, such as an implementation of the transport (TCP) and network and data link (IP) protocols. Microsoft Corporation provides an implementation of the TCP/IP protocol in the form of a kernel level device driver, also referred to as a transport protocol driver, named TCPIP.SYS 58. TCPIP.SYS 58 interfaces with the NIC device driver 54 via NDIS 56, an industry standard Network Driver Interface Specification jointly developed by Microsoft and 3Com. NDIS 56 defines an interface for communication between hardware-independent protocol drivers, such as TCPIP.SYS 58, which implement the Data Link, Network, and Transport layers of the ISO model, and hardware-dependent NIC drivers 54 which provide an interface to the NIC hardware and which correspond to the Physical Layer of the ISO model. A client program 60 on the NT server can communicate over the network 15 in accordance with the TCP/IP protocol by issuing suitable calls via the NT operating system to the TCPIP.SYS protocol driver 58, and the A series server 10 and NT server 48 communicate over network 15 at the physical layer of the ISO model.
To avoid the costs associated with the development of NIC cards for proprietary systems such as the A series enterprise server, it has been proposed in U.S. Pat. No. 6,289,388 also assigned to the present assignee and the contents of which are hereby incorporated by reference in their entirety, to provide a direct interconnection between A series enterprise server 10 and NT server 48 so that both systems may connect to a network via a shared network interface card installed on the NT server. Such an invention is implemented as part of a Cooperative Networking Platform (CNP) deployed on a Unisys ClearPath HMP NX computer system (xe2x80x9cthe ClearPath systemxe2x80x9d). As will now be described, the ClearPath system comprises a Unisys A Series enterprise server 100 and an Intel-based server 102 running Windows NT (xe2x80x9cthe NT serverxe2x80x9d).
As shown in FIGS. 3, 4, and 5, the CNP may take different forms. As illustrated in these figures, the interconnection couples the I/O subsystem of the A Series server 100 to the I/O subsystem of the NT server 102 to provide a relatively high speed data path between systems. Preferably, the interconnection comprises a physical connection between the I/O subsystems of the A series enterprise server 100 and the NT server 102 and an interconnection device driver that controls access to the physical connection by other software modules on the NT server 102.
In the embodiment of FIG. 3, the physical connection comprises a feedthrough card 62 installed in a channel adapter slot of the A Series server 100, an EISA Personal Computer Channel Adapter (EPCCA) card 66 installed in an EISA slot of the I/O bus of the NT server 102, and a CS-BUS II cable 64 that connects the CS-BUS II of the A Series server 100 to the EPCCA card 66 via the feedthrough card 62. The interconnection device driver (ICD) 70 is installed in the kernel space of the NT operating system and controls access to the physical connection (specifically the EPCCA card 66) by other modules on the NT server 102. The prior art embodiment of FIG. 3 also includes a Queue Service Provider module 76 that functions analogously to the QSP 28 of FIG. 1, a LANSG module 78 that functions analogously to the LANSG module 26 of FIG. 1, and NSM-stub and LLM stub modules 84, 86 of CNP.EXE 80 that function analogously to the corresponding components 30, 32 of FIG. 1. In addition, LDM and LLAH modules 82, 88 of CNP.EXE 80 are provided which function analogously to the similar components (not shown in FIG. 1) in a traditional Unisys networking architecture.
In FIG. 3, the interconnection device driver 70, including its PCCA and OPENCA drivers 72, 74, and the physical connection formed by the feedthrough card 62, cable 64, and EPCCA card 66, together define a Host Interface Function (HIF). The procedural interface between the QSP 76 and the interconnection device driver 70 of the HIF is designed to isolate the QSP 76 from the HIF. As will be apparent from the detailed description below, this enables the present invention to be employed with different implementations of the HIF. Specifically, the procedural interface between the QSP 76 and the interconnection device driver 70 is established through a process by which each module publishes entry points (i.e., pointers) to the procedures that implement its functionality, along with any required variable values. Another device driver entity maintains a record of these entry points, while the interconnection device driver 70 of the HIF registers the entry points and their attributes and the QSP 76 registers the entry points.
In order to invoke one of the entry point functions, a call is made to the registered entry point for that function. As a result of this indirection, different interconnection device drivers are installed for different implementations of the HIF in a manner that is completely transparent to the QSP 76.
FIGS. 4 and 5 illustrate two alternate embodiments of the HIF, which illustrate the modularity provided by the procedural interface design. In FIG. 4, the physical connection (i.e., the feedthrough card 62, cable 64, and EPCCA card 66) is replaced by a PCI Bridge card 67 that connects via a cable 65 directly to a port on one of the CMUs 18b of the IOM 14 of the A Series server 100. By connecting directly to the CMU 18b, some of the latency inherent in the CS-Bus II protocol is avoided. This provides a more direct, higher speed connection between the I/O subsystems of the two servers 100, 102. Because the physical connection is changed, a modified interconnection device driver 70= is provided. The modified interconnection device driver 70= comprises a single device driver module, PXN 73, that provides the interface between the QSP 76 and the hardware on the PCI Bridge card 67. However, the procedural interface, and the mechanism by which the QSP 76 and interconnection device driver 70= register entry points to the respective procedures of that interface is unchanged. Accordingly, the changes to the HIF are transparent to the QSP 76 and the other modules that comprise the Cooperative Networking Platform (CNP).
FIG. 5 is an embodiment in which the A Series server 100 is emulated through software in the NT server 102. Unisys provides such an emulated system in its ClearPath HMP NX 4200 series enterprise servers. In this embodiment, the physical connection is emulated such that it becomes a memory-to-memory connection 63 between the memory space of the emulated I/O subsystem 14 and the memory space of the NT system 102. The emulated connection 63 functions in a manner similar to the feedthrough card 62, cable 64, EPCCA card 66, and PCCA 72 components of the hardware implementation of FIG. 3. The interconnection device driver 70xe2x80x3 in this embodiment comprises a modified form 74= of the OPENCA module 74 of the implementation of FIG. 3. Again, however, the procedural interface between the modified OPENCA module 74= and the QSP 76 is not changed, so that the emulated A Series server 100 and its emulated connection 63 to the NT server 102 is transparent to the QSP 76 and the other modules of the present invention that comprise the Cooperative Networking Platform (CNP).
Also, a xe2x80x9cvirtualxe2x80x9d LAN device driver 79 and an NDIS Miniport Interface Library 81 together with LANSG and the remainder of the interconnection components in the systems of FIGS. 3-5 provide a high speed, low latency communications path between the A Series server 100 and the NT server 102 as described in U.S. Pat. No. 6,473,803 also assigned to the present assignee and the contents of which are hereby incorporated by reference in their entirety. As described therein, these modules, in combination with the physical connection (e.g., feedthrough card 62, cable 64, and EPCCA card 66) and the interconnection device driver 70), simulate a traditional channel adapter-based network processor of the type described above and illustrated in FIG. 1. VLAN 79 allows the A series enterprise server 100 and the NT server 102 to both use their native mechanisms to communicate with each other rather than conventional network communications paths such as Ethernet, which may be considerably slower. In particular, VLAN 79 allows the A series enterprise server 100 and the NT server 102 to communicate at the data link level of the ISO network reference model by simulating the physical level with the HIF.
A system which further improves the communications efficiency of the ClearPath system by simulating the TCP transport protocol and the IP networking protocol between the A series enterprise server 100 and the NT server 102 via the interconnect so that data may be transferred point to point between systems at the transport level rather than the data link level is described in U.S. Pat. No. 6,233,619, also assigned to the present assignee and the contents of which are hereby incorporated by reference in their entirety. By simulating the transport and network layer protocols, the system described therein removes the inherent limitations of the TCP/IP protocols by using a more reliable network connection through which larger blocks of data may be transmitted without being broken up into smaller data chunks with prepended network protocol information. Since the session level is unaffected, this is accomplished in a manner which is transparent to the user.
Another system has been described in WO 97/01944 in which a local host data processing system operating under the control of a local host operating system includes components of multiple emulating hosted operating systems. The host operating system includes a TCP/IP network protocol stack which couples the communications facilities of the host data processing system to a local area network for communicating with a number of remote host systems sharing the same TCP/IP network protocol stack. A virtual network is configured within the local host system for operative coupling to the host network protocol stack so as to provide access to well-known port application programs. In this configuration, the virtual network mechanism functions as another LAN by simulating the IP subnet to the TCP/IP stack to which multiple virtual host systems may be attached to a pretended IP address for each emulated system for executing applications under control of the emulating hosted operating systems.
However, the system described in WO 97/01944 can only use one TCP/IP network protocol stack. As a result, the system is not resilient and is further limited to an emulated environment or a single protocol environment. It is desired to provide a mechanism between the TCP/IP stack and the application programs which knows if the application is a local NT application or an MCP application in a particular environment and to establish a connection using one of the IP addresses available for each application environment in one of the available protocol environments. Thus, an independent IP address is used at connection establishment time by the communications server to connect only to the proper application environment. In other words, it is desired to provide a filtering mechanism between the application program and the TCP/IP stack so that multiple applications may be used simultaneously in multiple application environments in multiple protocol environments.
It is also desired to expand upon the systems described above to allow a known transport protocol executing on one computer system to be utilized by applications in other environments of a tightly coupled computer system in a way that is transparent to the application, i.e., no application programming changes are needed. It is further desired to provide better system performance by avoiding xe2x80x9ctransmissionsxe2x80x9d in the emulated LAN and avoiding the processing associated with manipulating the data frame content. The present invention provides such capabilities.
The present invention is directed to methods and apparatus that enable a transport protocol executing on a first computer system to be utilized by applications executing on a second computer system which is directly interconnected and closely coupled to the first computer system. Preferably, both systems use their native mechanisms to communicate with each other without affecting their native protocols, rather than over conventional network communication paths such as Ethernet. In accordance with a preferred embodiment thereof, the present invention comprises an interconnection that couples the input/output (I/O) subsystem of the first computer system to the I/O subsystem of the second computer system and over which data can be transmitted between the systems independent of a network interface card, and an interconnection messaging system and distributed transport communications manager executing on the first and second computer systems that together allow a transport protocol executing on the first computer system to be utilized by applications on the second computer system in a manner that is transparent to the application (e.g., no application programming changes are needed).
The interconnection between the I/O subsystem of the first computer system and the I/O subsystem of the second computer system preferably comprises a physical connection between the I/O subsystems over which data can be transmitted between them. The interconnection messaging system, on the other hand, includes a messaging subsystem (xe2x80x9cMSSxe2x80x9d) which provides general purpose transport interfaces to the first and second network protocol providers which is independent of communication protocols of the inter-connection and provides further interfaces on either end of the interconnection which are dependent on the communication protocols of the interconnection, whereby only the further interfaces must be changed when the interconnection is changed.
Preferably, the MSS includes a MSS component on each of the first and second computer systems, each MSS component having at least one local MSS user connected thereto through the interconnection independent interface. A MSS component on the first computer system creates a dialog to each complementary remote MSS user of the second computer system. Each MSS component includes means for building dialog tables for local MSS users informing the local MSS users about any complementary remote MSS users accessible via the interconnection and for updating the dialog tables as complementary remote MSS users are added or removed. Each MSS component also includes means for performing dialog management functions that allow the local MSS users to establish, receive status about, and destroy dialogs with the complementary remote MSS users over the interconnection. Each MSS component further includes means for performing control message functions which allow the local MSS users and the complementary remote MSS users to pass control messages to each other in a manner which is independent of the communication protocols of the interconnection. Each MSS component additionally includes means for transferring data between local and remote MSS users over dialogs established between the local and remote MSS users so as to optimize data transfers between the first and second computer systems.
The major advantage of the MSS of the present invention is the ability to isolate interconnect dependent mechanisms to a single component. In this manner, as additional functionality is added by implementing components which require inter-system communication via the interconnect independent MSS interface (i.e., as xe2x80x9cMSS usersxe2x80x9d), changes to existing interconnects as well as opportunities to incorporate additional interconnects may be accomplished entirely via the MSS components without affecting the MSS users.
In a presently preferred embodiment, one of the local and one of the remote MSS users are complementary components of a distributed transport communications manager which allows a known transport protocol executing on the first computer system to be utilized by applications on the second computer system. The complementary components of the distributed transport communications manager use the MSS and the transport protocol of the first computer system to provide dialog establishment, data transfer, and dialog termination between a network application executing on the second computer system and another network application executing in a computer network including the first and second computer systems. Also, the complementary components respectively interface with the network application executing on the second computer system and the transport protocol executing on the first computer system and are implemented on the first and second computer systems as complementary MSS users which are connected to the MSS through the independent transport interfaces of the MSS. Such techniques may be used to permit the transport protocol of the first computer system to be utilized by a plurality of networked computer systems including the second computer system or to permit applications executing on the second computer system to utilize transport protocols executing on a plurality of networked computer systems including the first computer system.
For reference, the computer system executing the transport protocol is known as the xe2x80x9cProtocol Environment,xe2x80x9d while the computer system executing the network application is known as the xe2x80x9cApplication Environment.xe2x80x9d The software modules which facilitate this functionality are collectively referred to as xe2x80x9cDistributed Transport Communications Management (DTCM)xe2x80x9d. DTCM contains both Application Environment and Protocol Environment components and relies on an underlying interconnect mechanism (the MSS). The Application Environment DTCM component is referred as the DTCM-Client while the Protocol Environment DTCM component is referred to as the DTCM-Server. DTCM-Client processes requests from network applications and, as needed depending of the nature of the request, utilizes the protocol stack executing in the Protocol Environment via requests issued to the corresponding remote DTCM-Server. DTCM-Server, by request of the DTCM-Client, interfaces to the local transport protocol. DTCM-Server maps requests from DTCM-Clients onto the corresponding local API functionality, reporting results back to the requesting DTCM-Client.
The scope of the invention also includes a method for enabling a transport protocol executing on a first computer system to be utilized by applications executing on a second computer system which is directly interconnected and closely coupled to the first computer system via an interconnection between an input/output (I/O) subsystem of the first computer system and an I/O subsystem of the second computer system to transmit data therebetween independent of a network interface using an interconnection messaging system on the first and second computer systems having a messaging subsystem (MSS) that provides general purpose transport interfaces between the first and second computer systems, use of the interconnection messaging system being controlled by a distributed transport communications manager (DTCM) having complementary DTCM components on the first and second computer systems, comprising the steps of:
the complementary DTCM components opening a MSS dialog over the interconnection;
the transport protocol of the first computer system and a transport entity in a computer network including the second computer system opening a transport dialog between the first computer system and another computer system in the computer network; and
managing the MSS dialog and the transport dialog so that the transport protocol of the first computer system may be used by a network application executing on the second computer system in a manner which is transparent to the network application.
In a preferred embodiment of the method of the invention, the method includes the additional steps of creating a plurality of MSS dialogs over the interconnection for a plurality of pairs of network applications whereby the network applications in each pair may communicate in a manner which is transparent to the native protocols of the network applications in the pair, and specifying the transport dialog which is to be used for the data transfer between the network applications in the pair.
The major advantages of the DTCM technique of the invention are:
1. The ability to utilize commodity software and hardware elements in the Protocol Environment, thereby avoiding costly development of those elements in the Application Environment. The use of commodity components also allows rapid deployment of new hardware and software functionality.
2. By xe2x80x9coff-loadingxe2x80x9d transport protocol processing to the Protocol Environment, processing cycles in the Application Environment are freed, allowing the Application Environment to perform additional tasks.
3. The Protocol Environment may be chosen to optimize network performance of the coupled systems as a whole.
Additional features and advantages of the present invention will become evident hereinafter.